-
Notifications
You must be signed in to change notification settings - Fork 8.2k
drivers: bluetooth: silabs: Add hardware-dependent feature detection #97994
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
@jrintaha fyi |
soc/silabs/silabs_s2/Kconfig
Outdated
| def_bool $(dt_nodelabel_bool_prop,radio,ble-2mbps-supported) | ||
|
|
||
| config HAS_HW_EFR32_RADIO_BLE_CODED | ||
| def_bool $(dt_nodelabel_bool_prop,radio,ble-coded-phy-supported) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need these intermediate symbols (HAS_HW_EFR32_RADIO_*)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think it is easier to define dependencies with these, like for example HAS_HW_EFR32_RADIO_CTE_RX
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a blocker, but I have always had some doubts about the benefit of adding new global helper symbols. They are sometime used to hide some logic (now or in further PR) and may make the reader work more difficult.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jerome-pouiller please see my comment
No strong change requests pending from me,
23169a0 to
46a301c
Compare
Vendor specific configuration is moved to a separate file. Signed-off-by: Ivan Pankratov <[email protected]>
Create a shared base binding (ble-radio.yaml) for common Bluetooth LE radio hardware capabilities to avoid duplication between vendors and ensure consistent property naming across the ecosystem. Properties are prefixed with 'ble-' and ordered chronologically by Bluetooth Core Specification version (5.0, 5.1, 6.0). Each property indicates a hardware capability, not current enablement state. Signed-off-by: Ivan Pankratov <[email protected]>
…-pins Rename generic FEM binding to use 'radio-' prefix for consistency with other radio bindings (radio.yaml, ble-radio.yaml). Updated 3 board files, Nordic BLE controller HAL, documentation, and test overlays. Added missing settle-time properties to pan1783a board. Signed-off-by: Ivan Pankratov <[email protected]>
Rename GPIO coex binding to use 'radio-' prefix for consistency with other radio bindings (radio.yaml, radio-fem-two-ctrl-pins.yaml). Updated beacon sample overlay and coex documentation. Signed-off-by: Ivan Pankratov <[email protected]>
Add migration guide and release notes entries for the radio-related devicetree binding renames: - generic-fem-two-ctrl-pins -> radio-fem-two-ctrl-pins - gpio-radio-coex -> radio-gpio-coex - tx-high-power-supported -> radio-tx-high-power-supported Also document the new radio.yaml base binding for generic radio hardware capabilities. Signed-off-by: Ivan Pankratov <[email protected]>
|



Summary
This PR creates a shared base binding for common Bluetooth LE radio hardware capabilities to avoid duplication between vendors and ensure consistent property naming across the Zephyr ecosystem.
Changes
New Base Binding
Updated Vendor Bindings
Silabs:
Nordic:
Silicon Labs Device Trees
Updated all Series 2 SoCs with hardware-supported features:
Nordic Device Trees
Updated with consistent property naming:
Kconfig Integration
Silabs - Added hardware capability flags (auto-detected from DT):
Silabs HCI driver automatically selects controller features based on hardware capabilities.
Nordic - Updated Kconfig to reference renamed properties:
Testing
Verified on all affected hardware (11 board configurations):
Design Philosophy
This approach harmonizes devicetree bindings across vendors while respecting each vendor's driver architecture.